| Developer(s) | GNU Project |
|---|---|
| Initial release | 1986 |
| Stable release | 7.3.1 / September 4, 2011 |
| Operating system | Unix-like, Windows |
| Type | Debugger |
| License | GNU GPL |
| Website | www.gnu.org/software/gdb |
The GNU Debugger, usually called just GDB and named gdb as an executable file, is the standard debugger for the GNU software system. It is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal, Fortran, Java[1] and partially others [2].
Contents |
GDB was first written by Richard Stallman in 1986 as part of his GNU system, after his GNU Emacs was "reasonably stable".[3] GDB is free software released under the GNU General Public License (GPL). It was modeled after the DBX debugger, which came with Berkeley Unix distributions.[3]
From 1990 to 1993 it was maintained by John Gilmore while he worked for Cygnus Solutions . Now it is maintained by the GDB Steering Committee which is appointed by the Free Software Foundation.[4]
GDB offers extensive facilities for tracing and altering the execution of computer programs. The user can monitor and modify the values of programs' internal variables, and even call functions independently of the program's normal behavior.
GDB target processors (as of 2003) include: Alpha, ARM, AVR, H8/300, System/370, System 390, X86 and its 64-bit extension X86-64, IA-64 "Itanium", Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, and VAX. Lesser-known target processors supported in the standard release have included A29K, ARC, ETRAX CRIS, D10V, D30V, FR-30, FR-V, Intel i960, 68HC11, Motorola 88000, MCORE, MN10200, MN10300, NS32K, Stormy16, and Z8000. (Newer releases will likely not support some of these.) GDB has compiled-in simulators for even lesser-known target processors such like M32R or V850.[6]
GDB is still actively developed. As of version 7.0 new features include support for Python scripting.[7] At least since version 7.3, "reversible debugging" [8] — allowing a debugging session to step backward, much like rewinding a crashed program to see what happened — has been added.
GDB offers a 'remote' mode often used when debugging embedded systems. Remote operation is when GDB runs on one machine and the program being debugged runs on another. GDB can communicate to the remote 'stub' which understands GDB protocol via Serial or TCP/IP. [9] A stub program can be created by linking to the appropriate stub files provided with GDB, which implement the target side of the communication protocol.[10] Alternatively, gdbserver can be used to remotely debug the program without needing to change it in any way.
The same mode is also used by KGDB for debugging a running Linux kernel on the source level with gdb. With KGDB, kernel developers can debug a kernel in much the same way as they debug application programs. It makes it possible to place breakpoints in kernel code, step through the code and observe variables. On architectures where hardware debugging registers are available, watchpoints can be set which trigger breakpoints when specified memory addresses are executed or accessed. KGDB requires an additional machine which is connected to the machine to be debugged using a serial cable or ethernet. On FreeBSD, it is also possible to debug using Firewire direct memory access (DMA) .
The debugger does not contain its own graphical user interface, and defaults to a command-line interface. Several front-ends have been built for it, such as Xxgdb, Data Display Debugger (DDD), Nemiver, KDbg, Xcode debugger, GDBtk/Insight and the HP Wildebeest Debugger GUI (WDB GUI). IDEs such as Codelite, Code::Blocks, GNAT Programming Studio (GPS), KDevelop, Qt Creator, MonoDevelop, Eclipse, NetBeans and VisualStudio (see VS AddIn Gallery) can interface with GDB. GNU Emacs has a "GUD mode" and several tools for VIM exist. These offer facilities similar to debuggers found in IDEs.
Some other debugging tools have been designed to work with GDB, such as memory leak detectors.
| gdb program | debug "program" (from the shell) |
|---|---|
| run -v | run the loaded program with the parameters |
| bt | backtrace (in case the program crashed) |
| info registers | dump all registers |
| disass $pc-32, $pc+32 | disassemble |
This is an example GDB session on the example program in Stack trace:
GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/sam/programming/crash Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xc11000 This program will demonstrate gdb Program received signal SIGSEGV, Segmentation fault. 0x08048428 in function_2 (x=24) at crash.c:22 22 return *y; (gdb) edit (gdb) shell gcc crash.c -o crash -gstabs+ (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y warning: cannot close "shared object read from target memory": File in wrong format `/home/sam/programming/crash' has changed; re-reading symbols. Starting program: /home/sam/programming/crash Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xa3e000 This program will demonstrate gdb 24 Program exited normally. (gdb) quit
The program is being run. After the cause of the segmentation fault is found, the program is edited to use the correct behavior. The corrected program is recompiled with GCC and then run.
|
|||||||||||||||||||